タスク管理は何をするのか 〜間のデザイン その２〜（倉下）
タスク管理は「間のデザイン」であると書いた。
では、その「間」では何が行われるのだろうか。具体的に見ていこう。
https://gyazo.com/3e030dc5c8009b2f89e662c2f4f17400
取捨選択
配置・再配置
具体化・細分化
意義の問い合わせ
ログ・実績確認
=== 取捨選択
まず、自分に向かってXから「これをやれ」という情報が発せされる。それは命令のときもあるし、依頼のときもある。さらに言えば「これをやろう」と決める自分自身がXになることもある。なんであれ、そのようなXから「やること」が生成される。
とは言え、それらすべてをやることはできない。よって、やることとやらないことを決めることが必要だ。さらに言えば、やることと、今はやらないことを決めることも必要である。タスク管理はそれを行う。
付言すれば、命令系統の混乱から「それは、私の作業ではない」という情報が、私向けに向かって発せられるときもある。そうしたときに、「これは私のやることではありません」と返送するのも、広義のタスク管理であろう。いわば、フィードバックをXに対して返しているわけだ。
=== 配置
「やること」の情報を、「やること」として受け取ったら、次はその配置である。それを「いつやるのか」を決める、ということだ。タスク管理におけるコアの働きがこの部分だ。
「やること」は、実行されなければならない。人間は、時間軸上に存在しているので、実行とは時間軸にその行動のための幅を設ける、ということを意味する。時間軸上の幅がゼロであるならば、その行動は永遠に実行されない。
難しく書いたが、簡単に言えば「いつやるかを決める」ということだ。今週なのか来週なのか。今週ならば何曜日なのか。今日がその曜日ならば、午前中なのか午後からなのか（それとも夜半からなのか）。そうしたことを決める。「やること」をタイムラインに配置する。
それだけではない。「やること」がより大きな枠組みの中にあるときは、「手順」を決めることも必要だ。まずAをやって、次にBをやって、最後にCをやる、という流れを決めるとき、それはそれぞれの「やること」を配置しているのだと言える。GTDがナチュラルプランニングと呼ぶのもこうした知的作業である。
=== 再配置
しかしながら、そうして配置したとして、その通りに進むとは限らない。アクシデントとトラブルはどこにでも潜んでいる。よって、配置したものを変更する作業も必要だ。
スケジュールが変わったら別の日に再スケジュールする。今日やろうとしてできなかったことは、別のできそうな日に移動させる。
プロジェクトの手順や段取りは、実際やってみてはじめて「思っていたのとは違う」とわかることもある。そうなったら、それに合わせて手順や計画を変更・修正していく。その修正・変更はf(x)の裁量を超えて影響を及ぶこともある。そうなったら、それはXへのフィードバックとなる。
こうした配置と再配置を繰り返していく作業は、Tak.によるアウトライン・プロセッシング、あるいはシェイクという概念に相当するだろう。
二軸での調整があるからこそ、それは現実的でありながら理想に向けた力を有する。
=== 具体化・細分化
Xからやってきた情報が、そのままでは実行が難しい場合がある。そうしたときには「具体的には何をすればいいのか」を考えることになる。これもタスク管理の重要な操作だ。
曖昧な目標指示に対して行動を具体化すること。あるいは、ある程度の具体的な行動を、細い手順に分割していくこと（細分化）。この二つが主要なプロセスである。タスク管理において「プロジェクト」と呼ばれるものについて「考える」とき、こうした知的作業が行われている。
細分化されれば、一つひとつの「行動」（タスク）は小さくなり、それを配置するバリエーションは大きくなる。組み合わせ方をいくらでも変えて行ける、ということだ。タスク管理の自由度を上げる上でも、この知的作業は意識したほうがよい。
=== 適切な配置
配置については、単に置くだけではない。うまい配置が手腕の見せ所だ。
午後に置いた方がよいもの、午前に置いた方がよいもの。ある作業と一緒に置いた方がよいもと、なるべくなら一緒におかない方がよいもの。
そうした組み合わせの妙も見据えることになる。
見栄えの良いリストではなく、「機能するリスト」を作り、それによって「出力」を補助するのがタスク管理の役割である。
=== 意義の問い合わせ
発生した行動・作業・タスクが、思考停止をしたまま進められるものであればよいのだが、そうではないものもある。自分自身でその意義に納得ができなかったり、明瞭に価値観と不整合しているものもある。他者発の「やること」だけでなく、自分発の「やること」であっても、それは起こる。
そうしたときに唯々諾々と進めるだけでなく、その行為の意義を確かめてみることも、一つの関数の役割だろう。当然、その答えをだすのは関数ではない。関数がコールバックした先である。しかし、その先が決定したことは、関数にも影響を与える。つまり、二つは繋がっている。
当然、こうした「手戻り」は、効率を一時的に落とすことになる。だから、生産性を最大化するならば、こうしたことは何も考えずに、ただ発生した「やること」を淡々とこなしていこう、という話になる。
しかしそれは危うい考え方であろう。企業の不祥事も、そうした思考の抑制から起きているのではないか。ただ全力でやってさえいれば、好都合な結果が必ずやってくる、と考えるのはあまりに人生の複雑さを軽視しているだろう。
ときには多少効率が落ちようが、波風が立とうが、発生源へのフィードバックを行ったほうがよい。それは私たちが「自由」であるために必要なコストである。
=== ログ・実績確認
行動という「出力」を生むだけがタスク管理の役割ではない。出力の結果を考慮して、関数の働きをかえていくことも必要だ。
行動数は目標に対してどうだろうか。多すぎる、ということはあまり考えられないが、少なすぎることはあるかもしれない。そうなれば、取捨選択や配置の基準を変更する必要がある。
一方で、自分の肉体については「多すぎる」という状況がありうる。ある日詰め込んで作業をしたら、その次の日にまったく使い物にならなかった、というのでは、一日の作業が多すぎることになる。一日単位で判断するのではなく、一週間や一ヶ月での「成果」を視野に入れる必要があるだろう。
そうした点を確認する上でも、記録（ログ）は重要だ。ログがなければ、記憶頼みになり、全体的な印象に引きずられてしまう。その上、細部はあっさりと抜け落ちる。私たちは短期的、瞬間的な判断は得意だが、中長期的なそれはむしろ不得意なのである。そういうときにこそ、記録・ノートは心強い支援者となってくれる。
また、自分がやったことが、「効果」があるのかも確認しておくことが必要だろう。Aを目指してやっているのに、Aにおける効果がほとんどない、というのではその「行動」をやる意義はなくなる。その結果は、Xにフィードバックしたり、f(x)自身の判断基準をかえていく情報になるだろう。
=== さいごに
タスク管理の「内部」で行われていることについて検討した。
以上述べてきたように、タスク管理は「ただリストを作る」ことだけを意味しない。リスト作りはコアとなる要素であるが、それが「入ってくる方」と「出て行く方」の両方に影響を与えている。また、それぞれとフィードバックの関係性を持ち、それらが交わって、非常に複雑なフィードバックループを形成している。
タスク管理は、単純なものではないのだ。
一方で、タスク管理の内部で行われることは、基本的には「単純化」である。実行する・しないを決め、作業を具体化・細分化していく。還元的なプロセスだ。
しかしながら、行動はあらゆるものに繋がっている。「思考する」ということですら行動の一形態にすぎない。だからこそ、行動に影響を与えるタスク管理は、あらゆるものに影響を与える。
この点を理解した上で、タスク管理を実践していくのがよいだろう。